home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10350 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.5 KB
  1. Path: cliffy.lfwc.lockheed.com!news
  2. From: Ken Garlington <GarlingtonKE@lfwc.lockheed.com>
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ crap knocks Ada
  5. Date: Thu, 07 Mar 1996 13:23:24 +0000
  6. Organization: Lockheed Martin Tactical Aircraft Systems
  7. Message-ID: <313EE34C.1DFB@lfwc.lockheed.com>
  8. References: <JSA.96Feb16135027@organon.com> <4hakfl$ogd@fred.netinfo.com.au> <313C749D.2C34@lfwc.lockheed.com> <4hk3qg$24ci@info4.rus.uni-stuttgart.de> <4hl106INNgjl@keats.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: cliffy.lfwc.lockheed.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (Macintosh; I; 68K)
  14.  
  15. Kazimir Kylheku wrote:
  16. > 
  17. > Under conditions where ultra-high reliability is required, I'd add a lot of
  18. > redundant check bits to every word of storage, and let the hardware do much of
  19. > the error detection and correction. It would be extremely irresponsible to use
  20. > unreliable hardware where the requirement is for ultra-high reliability, no?
  21.  
  22. Unfortunately, as you start adding complexity to the hardware, you start hitting
  23. other brick walls. Many of these systems, particularly the fail-operate ones,
  24. have to operate in extreme environmental conditions and various power failure modes.
  25. This limits the hardware complexity. Also, as you add complexity, the MTBF falls.
  26. Finally, as you add complexity, the chance of a hardware bug escalates. So, letting
  27. the hardware handle errors is not always the right answer.
  28.